Steps to reproduce

type: fleet
name: my-fleet

# Elastic/template fleet (provision on demand)
nodes: 0..1

backends: [runpod]
spot_policy: auto
idle_duration: 10m

dstack apply -f fleet.dstack.yml

Project        main
User           admin
Configuration  fleet.dstack.yml
Type           fleet
Fleet type     cloud
Nodes          min=0 target=0 max=1
Backends       runpod
Resources      cpu=2.. mem=8GB.. disk=100GB.. gpu=0..
Spot policy    auto

No matching instance offers available. Possible reasons:
https://dstack.ai/docs/guides/troubleshooting/#no-offers

Expected

dstack apply should show matching offers for elastic container-based fleets, since runs are provisioned on demand from those offers.

This is important not only for offer visibility/convenience, but also for consistency: VM-based elastic fleets already show offers during apply, and container-based elastic fleets should behave the same way.

Actual

No offers were shown for elastic container-based fleets during apply, even when offers existed.

Solution

Refactored fleet offer semantics to avoid duplicating branches while preserving behavior:

• Added get_fleet_offers(...) as the shared offer lookup for fleet planning/provisioning.
• get_fleet_offers(...) defaults to filtering by BACKENDS_WITH_CREATE_INSTANCE_SUPPORT.
• Removed get_create_instance_offers(...); create-instance paths now call get_fleet_offers(...) with include_only_create_instance_supported_backends=True explicitly.
• In get_plan(...), when nodes.target == 0, we call get_fleet_offers(...) with create-instance filtering disabled, so elastic Runpod/container offers are shown.
• Removed _is_elastic_cloud_fleet_spec(...) helper and switched to direct nodes.target semantics.

This keeps non-elastic behavior unchanged while fixing elastic container fleet offer visibility in dstack apply.

AI Assistance

This PR was prepared with AI assistance (Codex).